Over the past decade, enterprises have experienced a substantial increase in the productivity of its workforce when providing them with business mobile devices. In the past, given their high cost, business mobile devices were mainly allocated to management and focused on providing employees with email access and cellular phone capabilities. However, recent improvements in the computing power, mobile display technologies and connection speeds of mobile devices, combined with the continued decreases in hardware costs, have made powerful mobile devices available even to the general public for personal use. More and more individuals personally own powerful mobile devices, such as smartphones, that, in addition to serving as a cellular phone, can be used in many of the same ways as a desktop or a laptop, such as accessing emails, browsing documents or the internet, game playing, listening to audio or viewing videos, and personal information management (PIM).
Due to the above trends in mobile devices, enterprises are currently experiencing an “invasion” of personal devices into the workplace. Given the sophisticated capabilities of their personal mobile devices, employees no longer desire possessing separate personal and business mobile devices and continually pressure information technology (IT) departments to support personal devices brought into the workplace. As such, IT departments struggle to maintain a proper balance between enabling a certain level of access to enterprise data (e.g., such as access to email, contacts, documents, and the like) on personal devices and ensuring adequate security measures to protect corporate intellectual property in such enterprise data. This phenomenon has led enterprises to investigate the viability of a “Bring Your Own Device” (BYOD) strategy to IT, where a personal mobile device is provisioned by IT departments with the capability of operating as a complete business mobile device in a secure fashion.
Virtualization has been proposed as a solution for consolidating personal and business uses in a single mobile device. With virtualization, personal and work environments remain isolated. As a result, the user need not provide enterprise IT departments any control of the user's personal environment and the enterprise IT departments can retain strict control of the user's work environment. Another important feature of virtualization is that the user's work environment will be platform independent. Regardless of the type of personal mobile device the user chooses, the resulting work mobile device through virtualization will be identical. Therefore, enterprise IT departments need to support only one type of work mobile device.
When a mobile device is provisioned in the manner described above for both personal and work uses, it is not uncommon for a hypervisor to be hosted on an underlying host operating system (OS), and to rely on the host OS kernel memory allocation module to allocate machine memory of the host (as distinct from “physical” memory of a VM running on the mobile device, portions of which may not necessarily map to machine memory at any particular moment in time due to the capability of some hypervisors to allocate an amount of machine memory to a VM that may be more than a currently available amount of machine memory in the host) for both the hypervisor and any virtual machine (VM) instantiated by the hypervisor (e.g. a virtual work mobile device running on the personal mobile device). Further, it is not uncommon for the memory provisioned by the host OS kernel memory allocation module to the VM and hypervisor to be “pinned” such that the host OS cannot unilaterally revoke or modify the address or size of the memory allocation. That is, unlike ordinary applications on the host OS, the hypervisor is explicitly aware of the machine addresses of memory allocations, so pinning is required to prevent the host OS from unilaterally modifying those machine addresses. Memory allocations for the hypervisor and VM can remain pinned in the foregoing manner for extended durations because pinned pages are not immediately returned to the host OS when they are no longer required by the VM or hypervisor, but are instead reused by the VM and hypervisor. The long-lived pinned pages can, over time, fragment the machine memory of the host to such a degree that the host OS kernel cannot satisfy large, contiguous machine memory allocation requests from requestors such as applications, host kernel device drivers and subsystems, etc. Further, because all machine pages allocated to the hypervisor and VM are pinned, standard host OS kernel defragmentation mechanisms cannot operate on the pages to reduce fragmentation. As a result, even when sufficient free machine memory exists for the host OS to use separate from the pinned memory allocated to the VM and hypervisor, it may not be possible for the host OS to satisfy certain memory allocation requests, such as those requiring a large number of contiguous pages (i.e., 2n contiguous pages, where n>0).
Large contiguous page allocations are routinely required for page tables, the network stack and device drivers and therefore an inability to satisfy such memory allocations can be catastrophic for the host OS. The inability to satisfy large contiguous page allocations may result in the host OS attempting to swap certain machine memory pages to disk to free such memory pages with the hope that some of the freed pages will form sufficiently contiguous blocks to satisfy the request. Additionally, if the memory request is non-blocking (i.e., the request must be satisfied immediately and the thread invoking the request cannot be blocked (put to sleep) while waiting for memory to free up) and/or there exists no swap mechanism (as is the case with the Android® OS), an out-of-memory (OOM) “killer” component of the kernel, and in some implementations, a low memory killer component of the kernel, may be invoked, asynchronously terminating processes, some of which may be essential to sustaining the user experience on the mobile device. Worse, livelock, where the system consumes CPU cycles but makes no progress, can result as processes are terminated, restarted and terminated again when required. For example, the system may terminate process A to supply a large, contiguous machine memory page request made by process B. The system may then restart process A and terminate process B to supply a large, contiguous machine memory page request made by process A. Such a terminating and restarting loop, known as “livelock,” can repeat ad infinitum.